[小ネタ]StatusCheckFailedのテスト方法(Windows、Linux)
EC2インスタンスのステータスチェックでのテスト方法を纏めてみました。
StatusCheckFailed
EC2インスタンスのステータスでは、AWSシステム側の障害やOS側の一部の障害を起点にアクション(復旧、再起動)を設定できます。この起点となるのステータスが2種類あります。
システムステータスのチェック
EC2インスタンスが起動するAWSシステム(物理)を監視しています。AWSシステムの異常(以下、例)を検知するとステータスが不合格として表示されます。また、CloudwatchメトリクスのStatusCheckFailed_System
でカウントされます。
- ネットワーク接続の喪失
- システム電源の喪失
- 物理ホストのソフトウェアの問題
- ネットワーク到達可能性に影響する、物理ホスト上のハードウェアの問題
ステータスチェックに基づくアラームアクションを設定するときは、復元(EC2 Auto Recovery)を選択します。EC2インスタンスが稼働していたホスト以外で復元させる為です。なお、復元アクションは、システムステータスチェックだけ選択可能なアクションです。
インスタンスステータスのチェック
EC2インスタンスの異常(以下、例)を検知するとステータスが不合格として表示されます。また、CloudwatchメトリクスのStatusCheckFailed_Instance
でカウントされます。
- システムのステータスチェックの失敗
- ネットワークまたはスタートアップの設定が正しくない
- メモリの枯渇
- 破損したファイルシステム
- 互換性のないカーネル
インスタンスステータスはAWSシステム側の異常ではない為、ステータスチェックに基づくアラームアクションを設定するときは、再起動を選択します。
テストできるのはインスタンスステータスのチェック
前提としてテストできるのは、インスタンスステータスのチェックのみです。システムステータスのチェックはAWSシステム側のステータスなので私たちでどうやってもステータスをいじることができません。AutoRecoveryを設定するCloudwatchアラームで設定するシステムステータスチェックのメトリクスの閾値を調整してアラームを発生させることができますが、復元アクションはキャンセルしたとAWSから[Auto Recovery] Amazon EC2 instance recovery: No action taken [AWS Account: AWSアカウントID]
という件名でメールが通知されます。
本文には、アクション実行前にAWSシステムを再検証した上でAWSシステムは正常と判断したからAutoRecoveryしないと書かれていました。Cloudwatchアラームを意図的にアラーム状態にした場合などは上記の通り正常と判断するとのことです。
執筆時点ではシステムステータスチェックのテストをJIS元する方法がありません。なのでインスタンスステータスチェックのテスト方法を紹介してきます。
インスタンスステータスのチェックによるテスト方法
StatusCheckFailed_Instanceで設定するアクションは、Cloudwatchアラームで設定します。Cloudwatchアラームを発生させる方法として
- メトリクスの閾値を調整する
- OS側でNICを無効化する
いずれかでテストできます。ただし「1.」はインスタンスステータスのチェックというよりCloudwatchアラームのアクションを確認するという意味なので「2.」でインスタンスステータスを不合格とするテスト方法をご紹介します。
Linux
Amazon Linux2をベースにご紹介します。
EC2インスタンスでAmazon Linux 2を起動してStatusCheckFailed_InstanceでCloudwatchアラームを作成しておきます。
上記の通り、ステータスチェック、アラームの状態が正常な状態であればOKです。
EC2インスタンスにログインし、NICを無効にします。
$ sudo ifdown eth0
NICを無効にするとログインセッションは何も操作できなくなります。EC2コンソールを見てみるとステータスチェック、アラームの状態が異常な状態であることが確認できます。
Cloudwatchアラームの履歴を見るとステータスがアラーム状態に変わった後、アクションが実行されています。
再び、EC2コンソールを見てみるとステータスチェック、アラームの状態が正常な状態戻っています。
EC2インスタンスにアクセスするとログインすることができます。Linux全般はインターフェイスの有効化はeth0などの設定ファイル内でONBOOT=yes|no
で制御しているのでのがほとんどですが、アクセスできなくなった場合は、ネットワークインターフェイスを追加でアタッチすると自動でUPされます。万が一アクセスできなくなる場合も考えてAMIバックアップを取得してからテストすることを推奨します。
Windows
Windows2019で試してみます。
EC2インスタンスでWindows2019を起動してStatusCheckFailed_InstanceでCloudwatchアラームを作成しておきます。
EC2インスタンスにログインします。Linuxと違う点としてWindowsはDisable(無効)にしないとNICを停止できません。DisableはOS起動で自動で有効化されないたい為、OS起動時にNICを有効にするスクリプトを実行する必要があります。
任意の場所にNICを有効にするps1ファイルを作成します。内容は以下の通りです。
Enable-NetAdapter -Name "Name" -Confirm:$False
-Confirm:$False
で対話形式によるコマンド要求確認を無効にします。"Name"は、Get-NetAdapterで表示されるNameに読み替えて修正してください。
ps1ファイルを用意できたらタスクスケジューラを登録します。インポート用のxmlファイルを用意しました。
enable-adapter.xml
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<URI>\enable-adapter</URI>
</RegistrationInfo>
<Triggers>
<BootTrigger>
<Enabled>true</Enabled>
</BootTrigger>
</Triggers>
<Principals>
<Principal id="Author">
<UserId>S-1-5-18</UserId>
<RunLevel>HighestAvailable</RunLevel>
</Principal>
</Principals>
<Settings>
<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
<DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
<StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
<AllowHardTerminate>true</AllowHardTerminate>
<StartWhenAvailable>false</StartWhenAvailable>
<RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
<IdleSettings>
<StopOnIdleEnd>true</StopOnIdleEnd>
<RestartOnIdle>false</RestartOnIdle>
</IdleSettings>
<AllowStartOnDemand>true</AllowStartOnDemand>
<Enabled>true</Enabled>
<Hidden>false</Hidden>
<RunOnlyIfIdle>false</RunOnlyIfIdle>
<WakeToRun>false</WakeToRun>
<ExecutionTimeLimit>PT72H</ExecutionTimeLimit>
<Priority>7</Priority>
</Settings>
<Actions Context="Author">
<Exec>
<Command>C:\Windows\System32\cmd.exe</Command>
<Arguments>/C C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive -NoLogo -ExecutionPolicy Unrestricted -File "C:\script\enable-netadapter.ps1"</Arguments>
</Exec>
</Actions>
</Task>
39行目のps1ファイルパスは環境に併せて修正してください。
タスクスケジューラを起動し、タスクのスケジューラライブラリに移動してタスクのインポートをクリックしてxmlファイルを開きます。
ここのポイントはタスク実行時のユーザーはSYSTEMを指定しています。パスワードが指定不要なのでSYSTEMで実行します。
これで準備が整いました。PowershellからNICを無効にしてみます。
Disable-NetAdapter -Name "Name" -Confirm:$False
EC2コンソールを見てみるとステータスチェック、アラームの状態が異常な状態であることが確認できます。
Cloudwatchアラームの履歴を見るとステータスがアラーム状態に変わった後、アクションが実行されています。
EC2コンソールを見てみるとステータスチェック、アラームの状態が正常な状態戻っています。
再度、EC2インスタンスにログインできること確認できたらテスト完了です。
ネットワークが正常にならない場合
Linux、WindowsどちらもAMIバックアップを取得してから実行いただくのが安全ですが、もしAMIバックアップを取得していなくてネットワークが正常にならない場合は、EC2でネットワークインターフェイスを作成し、アタッチするとOS側で自動でNICを有効にしてくれます。今回確認したAmazon Linux2、Windows2019は追加のネットワークインターフェイスが自動で有効化されました。
まとめ
今回のポイントを纏めました。
- システムステータスチェックのテストはできない
- NICをダウンさせる前にAMIバックアップの取得を推奨
- Windowsは無効化した後は有効化する必要がある
- どうしようもないときはENIをアタッチしてみる
EC2インスタンスのステータスによる復旧テストを実施する際の参考になれば幸いです。